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(54) Method and apparatus for round trip software engineering 

(57) A method of round-trip engineering source 
code from a software model, and in particular a method 
of forward engineering code previously reverse engi- 
neered into a software model whereby to generate 
updated source code without any changes to the code 
not changed in the model, and without using obtrusive 
code markers in the source code. Elements from the 
original source code represented by the model are 
placed in a meta-model, and compared to a similar 
meta-modei of the software model. Appropriate 
changes and additions are made in the source code to 
elements which have been changed in the software 
model. The rest of the code in the software model 
remains untouched. 
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Description 

BACKGROUND OF THE INVENTION 

[0001] The present invention relates to software 
design modeling, and in particular to round-trip software 
engineering in which a software application is reverse 
engineered into a software model, the software model 
can be changed, and the code represented by the soft- 
ware model can then be re-coded. 
[0002] Due to inadequate software design mode- 
ling, application development projects have typically 
been very difficult to deliver with any kind of consistent 
success. A very low percentage of significant applica- 
tion development projects are completed on time and 
within budget. As projects have grown larger in scope, 
organizations have begun to partition applications and 
corresponding subsystems into multiple tiers, with each 
tier being developed and maintained ind^endently of 
the others. This enal>les applications to scale up to the 
ent rprise level. As more complex 3^ generation lan- 
guage projects are developed, a corresponding need for 
formal analysis and design modeling has increased. 
Accordingly, in order to combine various disjoint appli- 
cations into a single large scale solution, existing appli- 
cations need to be visualized and understood, without 
recourse to digging through the source code. Further- 
more, projects need to be re-engineered using compo- 
nent-based development techniques to rake advantage 
of various emerging object technologies such as 
GORBA, Microsoft ActiveX (OCX) and tiie World Wide 
Web. 

[0003] The first step required involves adding 
object-oriented analysis and design to the existing 
development process. As software needs become 
incr asingly complex, an environment is needed to 
complement the third generation lifecycle with an 
object-oriented analysis and design front end. enat>ling 
the application writer to take advantage of reusable 
components and track the development of the project. 
Many modeling products have been developed for this 
purpose, such as Platinum Technology. Inc.'s Paradigm 
Plus. The challenge in such products is to keep the 
design information synchronized vwth the code. 
[0004] As represented iri Figure 1. the capabilrty is 
required to keep a software model 2 up to date with 
changing source code 4. allowing the generation of eas- 
ily understood diagrammatic representations of the soft- 
ware design. This capability has been included in most, 
if not all. object modeling tools. Without this feabjre. a 
software model must be manually updated whenever 
changes are made in the design as the source code is 
written. This often leads to forgotten updates to the soft- 
ware model and a software model that Is out of date with 
respect to the source code that it is intended to repre- 
sent. 

[0005] As shown in the Venn Diagram in Figure 2. 
the problem is exacert>ated by the fact tiiat the software 



model generally only represents a subset of the infor- 
mation represented in the source code, and a large 
amount of meta-data concerning tiie project which is 
stored in the software model is not represented in the 

5 source code. For exarrple, neither comments in the 
source code nor properties of objects relating to tiieir 
formatting will generally be incorporated in tiie software 
nrrodel. Design principles and relationships between 
objects in the modeling methodology being used virtiich 

JO are represented in the software model, will not be 
included explicitiy in the source code. 
[0006] Several tools in the industry have added a 
round-trip engineering technology which can read the 
source code arrcl synchronize the software model with 

15 the source code. However, these tools rely on toeing 
able to place markers into tiie source code 4 to define 
areas of the code which correspond to the software 
model 2. These markers clutter the source code with 
extraneous marks, causing readability problems. In 

20 addition, this technique is prone to error when one of the 
markers is deleted or inadvertently edited by the devel- 
oper. 

[0007] What is required is a method of round-trip 
engineering allowing a software nrrodel to be kept syn- 
25 chronized with corresponding source code or equivalent 
objects, witiiout the need for code markers cluttering up 
the code. 

STATEMENT OF INVENTION 

30 

[0008] The present invention provides a system for 
keeping a software model representing a software appli- 
cation in synchronization with the source code it repre- 
sents without tiie need for any kind of source code 

35 markers delimiting parts of the code which are to k>e 
synchronized with tiie software model. The code in the 
software application is analyzed, and a software nrvxiel 
of the aspects of the application which can be incorpo- 
rated in the software model is generated. The software 

40 model is then used to regenerate the source code rep- 
resented by the software model, and any of tiie source 
code which is not represented in the software model te 
merged into the generated source code from the origi- 
nal code. 

45 [0009] These and other objects of the invention will 
be apparent from the remaining portion of this specifica- 
tion. 

BRIEF DESCRIPTION OF THE DRAWINGS 

50 

[0010] 

FIGURE 1 is a diagram showing an overview of the 
requirements of a round-trip engineering tool. 

55 

FIGURE 2 is a Venn Diagram representing tiie 
information stored in the source code for a project 
and a software model of tiie same project. 
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FIGURE 3A shc3ws an exported PowerBuilder 
object by way of example. 

FIGURE SB shows the PowerBuilder object of FIG- 
URE SB once it has been reverse engineered and 
forward engineered in accordance with bi-direc- 
tional engineering techniques known prior to the 
present invention. 

FIGURE 4 shows an overview of a round-trip engi- 
neering process in accordance with a first entiDOdi- 
ment of the invention. 

FIGURE 5 shows sample C+ + source code by way 
of example. 

FIGURE 6 shows a meta-model generated from the 
source code shown in Figure 5. 

FIGURE 7 shows tables in a database representing 
a software model. 

FIGURE 8 shows modified tables in a database 
representing a software model. 

FIGURE 9A shows a meta-model generated from 
the for source code shown in FIGURE 5. 

FIGURE 9B shows a meta-model generated from 
the software model shown in FIGURE 8. 

FIGURE 9C shows an updated meta-model based 
on the meta-models in FIGURES 9A and 9B. 

FIGURE 10 showing preliminary merge code 

FIGURE 11 showing final merge code 

FIGURE 12 showing overview of reverse engineer- 
ing (PowerBuilder) 

FIGURE 13 showing oven^iew of fonward engineer- 
ing 

DETAILED DESCRIPTION 



[001 1 ] As shown in Figure 1 . the embodiment of the 
invention hereinafter described relates to round-trip 
engineering of a software project between a software 
model 2 and the project source code 4. whereby the 
software model and the software can be kept synchro- 
nized. 

[0012] The primary example used to clarity tne 
operation of the embodiment and represented in Fig- 
ures 5-11 Is based around the C+ + programming lan- 
guage although tiiere is no reason the invention could 
not operate on other object oriented languages or other 
types of languages, as will become apparent. Lan- 



guages in which the objects are normally stored in pro- 
prietary binary formats can often be exported into flat 
file formats, such as ASCII Text Ffles with representa- 
tions of all the features of the objects, so that the objects 
5 can be re-imported back into the application. Examples 
of such applications are Microsoft's Visual BASIC. Vis- 
ual C+ +. Access and Sybase PowerBuilder. Often, cer- 
tain modules in these applications wrill be stored as flat 
source code files anyway, such a s C+ + -cpp files and 
to BASIC -bas files. 

[001 3] The software model 2 does not need to pro- 
vide all the concepts of the language of the source 
code, and v^rill normally provide modeling for tiie higher 
level concepts in the source code such as classes. 
15 attributes, operation/methods etc.. or data flow mode- 
ling between components. Many aspects of the source 
code, such as formatting of objects tiierein will often not 
be stored in the software model, but it is very important 
that such information is not lost in round-trip engineer- 
20 ing. For example, code exported from a Sybase Power- 
Builder application shown in Figure 3A includes 
information concerning the widtii. height and position of 
a window type class w_sort. Such information generally 
would not be included in a software model. If this code 
25 were reverse engineered into a software model 2. and 
then recreating using tiie software model per se. the 
code generated might have tiie appearance of tiie code 
shown in Figure 3B with much of the formatting informa- 
tion being lost in the round-trip. 
30 [0014] Furthermore, the language in which the soft- 
ware model 2 is generated will ideally be able to model 
various software development languages and therefore 
It is unlikely tiiat any particular language being modeled 
will support all tiie concepts supported by the modeling 

35 language. *u 
[0015] Accordingly a situation exemplified by the 
Venn Diagram in Rgure 2 arises, with the software 
model and the software development language sharing 
common concepts, but each having concepts not pro- 
40 vided by the other. 

[0016] For example, if the source code language 
were C+ +, the software model might provide for the 
modeling of 0+ + classes, structs. unions and enumer- 
ation classes with similar structures, although enumera- 
45 tion classes might be considered as a data type rather 
than a class in the software model. C+ + attributes could 
be mapped onto software model attributes, associations 
andyor aggregations depending on options passed to 
the reverse engineering utility and code situations. Addi- 
50 tional information, such as ^static" or "const'' might be 
marked in the operations' properties accordingly Global 
methods might be mapped to global operations in the 
modeling language. C+ + methods might be modeled as 
operations in the modeling language, and overloaded 
55 methods could be given an integer ID concatenated to 
their name to uniquely identify them in the software 
model. 

[0017] Many software modeling products, such as 



3 



5 



EP 1 001 338 A2 



6 



Platinum Technology, Inc.'s Paradigm Plus are currently 
available which permit generation of software models 
from source code using various different modeling 
methodologies, and also permit the generation of 
source code from the software model. The following 
description of the operation of the invention assumes 
tfiat the necessary functionality is already in place to 
generate such software models and regenerate source 
code from these software models and accordingly does 
not address the actual representation of the software 
model, except by way of example. 
[0018] The source code 4 of a software project, 
which will generally consist of a set of files stored on a 
computer or a network or computers. The present 
invention provides a method for round-trip engineering 
of source code using an implementing an improved sys- 
tem for forward engineering. 

[0019] As stated above, standard techniques are 
used to generate a^ftware model, or to augment a 
software model 2 already generated. The software 
model can then be forward engineered to generate 
source code for the project as shown. Importantly, when 
a software project is reverse engineered from source 
code, and the software model generated is forward 
engineered, the resultant code should be essentially the 
same, regardless of what information in the source code 
is represented in the software model. This allows for 
proper ^'round-trip" engineering of the software project, 
so that the software model and the source code can be 
kept synchronized, updates in both the source code and 
the software model will be maintained when generating 
the source code from the software model and vice 
versa, and comments and other features of the source 
code not represented in the software model do not get 
moved around or even disappear in the round-trip proc- 
ess. 

[0020] The operation of the round-trip engineering 
of the specific embodiment of the invention described is 
shown in broad terms in Figure 4. 
[0021] Reverse engineering 10 is carried out in a 
normal manner, but importantiy, during forward engi- 
neering 12, the existing source code 4 is merged with 
the data from the software model 2 whereby to generate 
new source code 8 which then replaces the existing 
source code. Corresponding sections of the source 
code are identified for each element in the software 
model 2. and any changes, additions or deletions that 
have been made in the software model and which do 
not correspond to the source code are incorporated in 
the new source code 8. without affecting any parts of 
the source code not represented by the software model. 
[0022] The operation of the specific embodiment of 
the invention is hereinafter described with reference to 
Figures 5-11. The invention relates to fonward, reverse 
and round-trip engineering from any software language 
to a software model representing the software. An 
example of the operation of the emtxxliment is given 
with reference to the C + + programming language, 



although the emt>odiment is equally applicable to other 
programming language, and kieally would be able to 
handle multiple programming languages. The invention 
is in no way limited to the constructs used by the C+ + 

5 programming language. The invention primarily relates 
to the merging of the source code and the data in the 
software model, where possible retaining the original 
source code without recourse to markers in the code. 
The actual contents of the code are not relevant to the 

70 invention. 

[0023] Source code 4 in source code files 40, writ- 
ten in a particular programming language are reverse 
engineered into a new software model 2 or incorporated 
into an existing software model 2. and then forward 
75 engineered from the software model 2 into a new set of 
source code files 80, or merged with existing source 
code files 40 without recourse to new source code files. 

REVERSE ENGINEERING 

20 

[0024] Reverse engineering according to this 
embodiment is effected by parsing the code and trans- 
forming all the elements of the code which can be rep- 
resented by the software model into a generic meta- 

25 model, for example using the CASE Data Interchange 
Format (CD IF) which is commonly used as a generic 
standard representation format for software entities. 
Details of the CDIF set of standards can be obtained 
from the Electronic Industries Association CDIF Techni- 

30 cal Committee. From the generic meta-model, the ele- 
ments of the code which can be represented in the 
software model selected are exported into the software 
model. The method of exporting the data from the theta- 
nrKxJel to the software model will depend on the format 

35 of the software model and meta-model generated, but in 
most cases wilt simply involve populating a datat>ase 30 
of elements. The software model 2 of this embodiment 
of the invention uses a datat^se comprising tables 22, 
23. 24. 25 to represent the data. 

40 [0025] The software model 2 need not be in data- 
base format, and might be stored in any kind of data 
structure. In the database shown in Figure 7, different 
elements of the application are classified by type into 
tables 22. 23. 24, 25 with appropriate fields to represent 

45 all the properties of the elements, and cross reference 
them to other associated elements appropriately. The 
format of these tables will vary depending primarily on 
the methodology embodied by the software model to 
represent the software being modeled. For e^mple, the 

50 software model shown in Figure 7 represents classes, 
attributes, operations, associations, the relationships 
therebetween and other features thereof. These con- 
structs can be used to represent constructs in many 
object oriented languages. For example. C+ methods 

55 can be represented as operations in the software 
model, and C+ + constructs of the types CLASS, 
STRUCT, UNION and ENUM can all be represented as 
classes in the software model. The software model 
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might also hold infamation relating to other software 
entities such as objects or data flow between entities. 
Four tables are shown in Figure 7. each holding irtfor- 
mation relating to classes, attributes, operations and 
associatior^. The two classes X and Y in the Classes 
table 22 are given integer identifiers which the software 
model uses to identify them. Other features of the 
classes are also stored in the table, such as the source 
file of the class in question, and the type of the class in 
question, such as CLASS or STRUCT. Certain of the 
fields provided by the software model for each of the 
classes might be inapplicable to the software language 
being modeled, and can be left empty. 
[0026] Each entry in the attributes table 23 has a 
field representing the name of the attribute, and the 
owning class. Other fields might be the scope of the 
attribute, the type, and the source file. As attributes 
might be overloaded, ie. cOfferent attributes in different 
classes sharing the same name, the name given to the 
attribute in the software model might need to be modi- 
fied to distinguish between commonly named attributes 
and an alias given for the attribute in question. Alterna- 
tively, attributes could be given arbitrary identifiers as 
key values in the table, so that more than one attribute 
could share the same name. The same principle would 
be used for other constructs which could be overloaded, 
such as operations. 

[0027] Records in the operations table 24 contains 
operations, which in this example would hold C + + 
methods and functions. These records likewise have 
fields for the owning dass. if there is one. In this exam- 
ple based around C+ +. a source file field in this table 
would refer to the actual file containing the source code 
for the method, rather than the source file containing the 
declaration of the method, as the latter could be derived 
from the source file of the owning class. 
[0028] Finally, the associations table 25 contains 
associations between classes. In this example, 
attributes which are of a class type are stored as asso- 
ciations, although they could be stored in the attributes 
table with the type set to the dass name. The owning 
class field stores the dass in which the attribute is 
defined, and via which it is accessed. The member 
class stores the dass of which the attribute is a type, 
that is to say, the class type of the attribute. 
[0029] Reverse engineering of object based lan- 
guages, rather than source code can be achieved by 
exporting all the information encapsulated in the objects 
into a fiat file format, for example ASCII, and then 
importing any information which can be represented by 
the software model 2 from the exported file into the 
GDIF meta-model and from there innported into the soft- 
ware model- The step of representing the data in the 
GDIF format could be avoided. However, using the inter- 
mediate step of generating a CDIF format file has the 
advantage that standard utilities which are already in 
existence for transforming data from various source lan- 
guages into CDIF Format can be used, and a single util- 



ity can then be used to import the data from CDIF 
format into the software model. If the software model 
were to be generated directly from the source code, a 
diffaent utility would need to be generated for each 
5 source language supported by any particular software 
model format. Figure 12 shows a an example of the 
operation of reverse engineering according to tiie inven- 
tion on a set of PowerBuilder objects. If tiie invention 
were operating on C + + source code, the exporting step 
10 would not be necessary, and the code could be trans- 
formed directiy into CDIF Format. 
[0030] If a software model 2 is already present 
when the data from tiie source file is imported into the 
software model, and data from the source file is to be 
15 merged into the software model rather tiiari replacing it. 
a chedc is made before adding elements into the data- 
base for corresponding elements already in tiie data- 
base. If a con-esponding element is not found, the 
element is simply added to the datafc>ase. 
20 [0031] If a corresponding element is found in the 
database and the data fields which are defined in botin 
the element to be merged and the corresponding ele- 
ment already in the table match, any data fields defined 
only in the element being imported are incorporated in 
25 the existing fields for the corresponding elements and 
the other fields are left untouched. 
[0032] If a corresponding element is found in the 
database and the data fields which are defined in botii 
the element to be merged and the corresponding ele- 
30 ment already in the table do not match, contention han- 
dling is used to ascertain whether the imported element 
or the element already in existence will have priority. For 
example, a message box could be displayed reporting 
tiie contention and asking which data should be used in 
35 the software model. Which of the imported data and tiie 
data already present has priority could also be preset 
before the import commences so that no contention res- 
olution is necessary. 

[0033] Furthermore, a check could also be made 
40 tiiat all the data in ttie software model associated witii 
ttie source file or source files being imported were actu- 
ally among the elements imported. Any mismatch would 
correspond erther to elements added to the software 
model or elements removed from tine source code since 
45 tiie software model and tiie source code were last syn- 
chronized. If logging of additions to the softv^are model 
are made, a simple check of the logged additions would 
allow ttie importing utility to ascertain whettier the ele- 
ment had been added to the software model or removed 
50 from the source code and take appropriate action. In tiie 
latter case, a message box could be provided asking if 
the element should be removed from the software 
model. 



55 FORWARD EN GINEERING 

[0034] Fonward engineering is effected by merging 
tiie data in ttie software model 2 with any existing 



5 



9 

source code 4, adding new code, changing code or 
removing code when necessary to create new source 
code 8. Inportantly. existing source code not affected 
by changes in the software model is left unchanged. An 
example of the forward engineering process which 
could be used to generate a PowerBuilder project, after 
reverse engineering in accordance with Figure 12, is 
shown in Figure 13. The Forward Engineering process 
will generally be used to modify source code based on 
modifications to the software model, or to create new 
source code. The present invention provides a system 
for doing the former, and the process is explained with 
reference to Figures 8 to 11 wherein Figure 8 shows a 
software model 2 being a modified version of the soft- 
ware model shown in Figure 7. 

[0035] As mentioned already, fields in the software 
model 2 might not be transferrable into the source code. 
For example, a field might be provided in the represen- 
tation of a dass in the software model identifying a doc- 
ument containing an explanation of the function of the 
class in question. Such fields can be populated in the 
software model to aid in the software design without 
being incorporated into the source code, and. as dis- 
cussed above, will not be affected by reverse engineer- 
ing of the source code because corresponding data 
which might cause a contention would never be 
imported from the source code. 
[0036] Returning to Figures 9A and SB, when per- 
forming forward engineering of a source code file, a 
generic meta-model 80 of the data in the source file or 
files being forward engineered, and a generic meta- 
model 82 of the data in the software model are first gen- 
erated. Meta-models which might be generated from 
the modified software model shown in Figure 8 and the 
origir^l source code shown in Figure 5 are shown In 
Figures 9A and 9B respectively. The meta-models might 
for example be generated in CDIF format, as discussed 
atxjve with reference to the reverse engineering proc- 
ess. The generic meta-model format used must permit 
representation of all the elements of the source-code 
that can be represented in the software model and vice- 
versa. The use of the generic meta-model makes it pos- 
sit)le to compare the two different data sources. Map- 
pings from each specific environment to the generic 
meta-model are developed to ensure that no data is lost 
and the appropriate information is compared. Further- 
nrx>re, only the elements from the software model which 
should be present in the source-code file being forward 
engineered are extracted. For example, all the classes 
stored in the software model 2 with their source-code 
file field corresponding to the source-code file will be 
brought into the meta-model 82. and all the attributes, 
operations and associations owned by those classes. 
Classes and other objects from source-code files other 
than the source-code file being generated are not 
placed in the meta-model. For example, as shown in 
Figure 9A, Class Z is not put in the meta-model. as it 
does not form part of source-code file A (see Figure 8). 



10 

If more than one source file is to be generated in the for- 
ward engineering process, the method described for for- 
ward engineering will be carried out for each source file 
and the appropriate data extracted form the software 

5 model 2 in each case. 

[0037] The operation of the meta-model generation 
and the nature of the meta-models generated will 
depend on the structure of the programming language 
and the constructs therein, as well as the constructs 

10 used in the software model. It must be possible to 
search through the elements in the source-code meta- 
model 80 and identify corresponding elements from the 
software model 2 and the source code 4. For example, 
different classes, variables and other independent 

15 Structures in the source code such as STRUCT and 
UNION structures could be stored in a linked list Ele- 
ments owned by these structures could be placed in a 
linked list pointed to by the appropriate element in the 
main linked list. Searching for elements is then easily 

20 accomplished by passing down the linked list, finding 
the appropriate elements, and if necessary then looking 
though the appended linked list associated with that ele- 
ment. 

[0038] Importantly, each element in the generic 

25 meta-model generated from the source code has asso- 
ciated with it a line number 84 and a "change state" 86. 
The line number con-esponds to the line numtDer of the 
element in question in the original source code. In alter- 
native embodiments of the invention, the actual start 

30 and finish points in the code associated with any partic- 
ular element could be stored in the software model, 
rather than just the line number, so that multiple ele- 
ments on one line can be independently merged. For 
example, in the example meta-model generated from 

35 the source code shown in Figure 9A, the line numbers 
84 are shown in the center column. 
[0039] The change state 86 Is shown in the right 
column for each of the elements in Figure 9A It can 
have one of four values: Added. Deleted, Modified and 

40 None. Initially, when the meta-model Is generated, the 
elements will all have an undefined change state, to rep- 
resent that the merge has not yet commenced, and no 
changes have been made to the meta-nrtodel, as shown 
in Figure 9A. 

45 [0040] The meta-model 82 generated for the soft- 
ware model 2 does not require the line numt>ers 84 and 
change states 86 as will become apparent. A represen- 
tation of a meta-model generated for the software nnodel 
2 is shown in Figure 9B. 

so [0041] A search is made over the generic meta- 
model 80 of the source code 4 for a corresponding ele- 
ment to each element in the meta-model 82 for the soft- 
ware model 2. 

[0042] ff a corresponding element is not found, the 
55 element is added to the meta-model for the source 
code, and the element's "ChangeState" is set to 
"Added". 

[0043] ff the element is found but there Is a param- 
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eter mismatch, the parameters are changed to the 
updated parameters., and the change state of the corre- 
sponding element is set to "Modified". A representation 
of the replaced parameters would be stored in a file, or 
in the meta-model so that an appropriate log can be 
made at the end of the Fonward Engineering Process. 
[0044] If the element is found, and the parameters 
of the element match, the change state is set to "None** 
to reflect that there are no changes. 
[0045] Once all the elements have been searched 
for, any elements that have not had their change state 
set must have been removed from the software model. 
These elements have their change state set to 
"Deleted". The Change States of all the elements could 
initially be set to "Deleted" before the search instead of 
being left empty to avoid passing through all the ele- 
ments a second time. 

[0046] To avoid having to generate the second 
generic meta-model 82, the elements in the meta- 
model format generated from the software model 2 
could instead be compared with the meta-model 80 as 
they are generated As each element is compared, the 
same actions described above would be carried out to 
set the change states, resulting in the same merged 
meta-model. 

[0047] It should be noted that it is assumed in the 
above processing that the software model is assumed 
to be the correct version and the source code is 
assumed to be out of date. However, the two could be 
synchronized if updates to the source code and the soft- 
ware model were previously logged, and the information 
in the log used to decide which of two con-esponding 
elements in the two meta-models had priority when the 
software model and the source code do not agree. 
Reverse engineering would then have to be performed 
to bring the software model into line with the new source 
code generated. This would effectively be the opposite 
round-trip engineering, starting with Fonward Engineer- 
ing. It is generally simpler to the round-trip engineering 
in the conventional order and the associated merging 
procedure with the software nruxlel having priority is 
therefore the procedure dealt with herein in detail. 
[0048] The updated meta-model 88 resufting from 
this process is shown in Figure 9C with the operation 
doThatO added and the attribute 3 deleted from the 
source-code meta-model. 

[0049] A new version of the source code file is then 
generated from the original source code file shown in 
Figure 5 and the generic-meca model. The new version 
could be constructed in a file, in a one<iimensional text 
an-ay with an entry for each line of code, or by placing 
the source code in a linked list with one entry for each 
line of code- Two essentially different approaches could 
be used for inserting new lines of code into the source 
code. The new source code could be added to the end. 
and appropriate mappings generated from an index, or 
the lower part of the data structure in question could be 
shifted down expanded and the new code slotted in. 



This would generally be easier if the constmction was 
taking place in a linked list or an array. It is assumed in 
this example that new code is added to the end of a file, 
and an index of positions in the f He for each line of code 
5 updated appropriately, as shown in Figure 10. The fol- 
lowing procedure is then earned out for each dements 
in the generic-meta model of the code: 
[0050] If the change state is None, noting is done to 
the associated source code. 
10 [0051 ] If the change state is "Deleted", the appropri- 
ate line is found in the new source code file using the 
index, and the line is removed using syntax specific 
comments (i.e. commenced out). For example, in C+ +. 
this would involve using comments /* and */ at the 
15 beginning and end of the line. Atternatively. the code 
could actually be removed, and the removed text could 
be recorded in a log f ile. In this case, the index position 
for the line removed would be deleted, and all the other 
index locations below it moved up by one. 
20 [0052] If the change state is "Added", the appropri- 
ate place to add the new code is established. For exam- 
ple, if the new element is a member of a class, the last 
line in the class is found by scanning through all the ele- 
ments in the dass and adding 1 to the highest line 
25 number found. Alternatively, the end of the class could 
actually be included in the generic meta-oKXiel with the 
dass element in question, along with the first line 
nunt>er in the class, or a scan of the actual source code 
could be made to find the last line in the class. A new 
30 line or new lines are added to the end of the source 
code and appropriate code for the element is entered 
therein. The appropriate point relative to the last line in 
the class in the original source code is found in the 
index, and references to the new lines of code inserted. 
35 All the index entries below this point are moved down 
appropriately The result of this operation inserting the 
method doThatQ is shown in Figure 10. 
[0053] If the change state is "changed", the appro- 
priate index entry is found for the line, and appropriate 
40 changes made to the code. 

[0054] Once all the necessary changes and addi- 
tions have been made, a pass is made through the 
index and the corresponding lines of code from the 
merged source code file or data structure representa- 
45 tive thereof are extracted and written to a new ffle in the 
correct order as shown in Figure 1 1 . The original source 
cxxle file is then replaced by the new source code file. 
[0055] The generated code will be identical to the 
original code except where changes have been made in 
so the software model. 

[0056] In a modification of this embodiment, prelim- 
inary source code is generated from the source-code, 
and the source-code thus generated is merged with the 
original source code. The merging of the two sets of 
55 source code could be accomplished by generating a 
meta-model as described above for both the original 
and the generated set of source-code. In this case, the 
meta-model for the generated source-code would corre- 
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spond precisely with the meta-mcxjel 82 for the software 
model, and the procedure would carry on exactly as 
described above, in effect, an extra step of converting to 
source code would have been inserted in the generation 
of the software model meta-model 82 from the software 5 
model 2. 

[0057] Alternatively, the step of convening both sets 
of source code into a meta-model could be eliminated, 
and a utility could parse through both sets of source 
looking for corresponding elements and updating the 10 
original source-code appropriately. The operation of this 
utility would be similar to the operation of the system for 
comparing the two meta-models described atxsve, but 
would require tracking which class or structure the code 
being scanned through forms a part of. However, it is 
would generally be much simpler to create a meta- 
model representing the code in a data structure than 
actually trying to analyze the code on the fly. and this 
method of merging the software model and the source- 
code is not considered to be preferable. 20 
[0058] While preferred embodiments of the present 
invention have been illustrated and described, it will be 
understood by those of ordinary skill in the art that 
changes and modifications can be made without depar- 
ture from the invention in its broader aspects. Various 25 
features of the present invention are set forth in the fol- 
lowing claims. 

Claims 

30 

1 . A method of synchronizing a software model and 
existing source code by generating updated source 
code, said source code comprising elements which 
can be represented in said software model and ele- 
ments which cannot be represented in said soft- 35 
ware model, said software model allowing graphical 
representation of the intercommunication between 
said representable elements of said source code; 
said method comprising the steps of: 

40 

a) comparing representations of each software 
model element with a corresponding element, if 
any. in the source code; 

b) generating new source code for each said 
software model element if said element differs 45 
from its corresponding element in the existing 
source code because said element has been 
updated in the software model; and 

c) incorporating said new source code into said 
existing source code; and so 

d) storing the combined new source code and 
the remaining existing source code on a stor- 
age medium, 

2. A method in accordance with Claim 1 said step of ss 
conparing representations comprises the steps of: 

1) generating a first set of elements represent- 
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ing elements of said original source code in a 
first intermediate model using an intermediate 
model architecture, said intermediate model 
being able to represent said elements which 
can be represented in said software model, 
said representation of each element in the first 
intermediate model including a reference to the 
location in the source code of the correspond- 
ing element; 

2) generating comparison elements represent- 
ing elements of said software model in said 
intermediate model architecture; and 

3) comparing each of said comparison ele- 
ments to said elements in said first intermedi- 
ate model; 

and wherein said step of generating comprises 

generating new source code for each of 
said elements in said first intermediate 
model if said corresponding comparison 
element differs therefrom. 

3. A method in accordance with Claim 2 wherein an 
element is added to said first set of elements corre- 
sponding to said comparison element if said com- 
parison element is not found in said first set of 
elements, and wherein said added element in said 
model is incorporated at an appropriate place in 
said source code when generating said updated 
source code. 

4. A method according to Claim 1 wherein the source 
code elements for which no corresponding software 
model elements are found are removed from the 
existing source code. 

5. A method according to Claim 4 wherein said source 
code elements are removed by convening said 
source code elements into source code comments. 

6. A method according to Claim 1 wherein said source 
code elements each represent the contents of a line 
of said source code. 

7. A method according to Claim 1 wherein said source 
code elements each represent a single entity in 
said source code. 

8. A method according to Claim 1 wherein the steps of 
comparing, generating and incorporating are pre- 
ceded by the steps of generating an original soft- 
ware model from said existing source code and 
updating elements in said original software model 
to generate said software model. 

9. Apparatus for synchronizing a software model and 
existing sourc code by generating updated source 
code, said source code comprising elements which 
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can be represented in said software model and ele- 
ments which cannot be represented in said soH- 
ware model architecture, said software model 
allowing graphical representation of the intercom- 
munication between said representable elements 5 
of said source code; said apparatus comprising: 

a) means for comparing representations of 
each software model element with a corre- 
sponding element, if any, in the source code; 10 

b) means for generating new source code for 
each said software model element if said ele- 
ment differs from its corresponding element in 
the existing source code kjecause said element 
has been updated in the software model; and is 

c) means for incorporating said new source 
code into said existing source code; and 

d) means for storing the combined new source 
code and the remaining existing source code. 

20 

10. Apparatus according to Oaim 1 wherein said 
means for comparing representations comprises: 

1) means for generating a first set of elements 
representing elements of said original source 25 
code in a first intermediate model using an 
intermediate model architecture, said interme- 
diate model being able to represent said ele- 
ments which can be represented in said 
software model, said representation of each 30 
element in the first intennediate model includ- 
ing a reference to the location in the source 
code of the corresponding element; 

2) means for generating comparison elements 
representing elements of said software model 35 
in said intermediate model architecture; and 

3) means for comparing each of said compari- 
son elements to said elements in said first 
intermediate model; 

and wherein said means for generating com- 4C 
prises 

means for generating new source code for 
each of said elements in said first interme- 
diate model if said corresponding compari- 4i 
son element differs therefrom. 



the existing source code for which no conespond- 
ing software mode! elements are found. 

13. Apparatus accorcfing to Claim 12 wherein said 
removing means removes said source code ele- 
ments by convening said source code elements into 
source code comments. 

14. Apparatus according to Claim 9 wherein said 
source code elements each represent the contents 
of a line of said source code. 

15. Apparatus according to Claim 9 wherein said 
source code elements each represent a single 
entity in said source code. 

16. Apparatus according to Claim 9 further comprising 
means for generating an original software model 
from said existing source code and allowing the 
updating of elements in said original software 
model to generate said software model. 



11. Apparatus in accordance with Claim 10 comprising 
means for adding an element to said first set of ele- 
ments conesponding to said comparison element if 
said comparison element is not found in said first 
set of elements, and means for incorporating said 
added element in said model at an appropriate 
place in said source code when generating said 
updated source code. 

12. Apparatus according to Claim 9 further comprising 
means for removing the source code elements from 
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FIGS 



r This is a library file */ 1 
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Class X ^ 

intattV. 6 

Z att2; 7 

void doThisQ; ^ 

} ^ 

^ 10 

rimportant comment about Class Y*/ 11 

class Y 13 
{ 

int attS; '^^ 
void doTheOtherO 
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FIG 10 

File 

/* This is a library file */ 



class X 
{ 

int atti; 
Zatt2; 

void doThisO; 

} 

/'Important comment about Class YV 

class Y 
{ 

r int att3; V 

void doTheOtherO 

} 

void doThat(); 
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FIG 11 



' This is a library file V 

class X 
{ 

intatti: 
Zatt2: 

void doThisO; 
void doThatO; 

} 

/•Important comment about Class YV 

class Y 
{ 

Tint att3;V 

void doTheOtherO 

> 
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